What the bug is

handleOAuthUnauthorized (auth.ts:186-194) now computes:

const unionScope = computeScopeUnion(tokens?.scope, ctx.scope, challenge.scope);
const forceReauthorization = isStrictScopeSuperset(unionScope, tokens?.scope);

isStrictScopeSuperset (auth.ts:638-645) treats an undefined/absent current scope as the empty set, so it returns true whenever unionScope is non-empty and the stored token record has no scope field. Per RFC 6749 §5.1, authorization servers commonly omit scope from the token response when the granted scope equals the requested scope, and exchangeAuthorization/saveTokens store exactly what the AS returned — so tokens?.scope === undefined is the normal steady state for many providers, not an edge case.

The code path that triggers it

This PR newly threads the transports' accumulated _scope (and resourceMetadataUrl) into ctx.scope on every 401 for Streamable HTTP _send/_startOrAuthSse and legacy SSE, all of which route through adaptOAuthProvider → handleOAuthUnauthorized. So the trigger only requires that any earlier WWW-Authenticate challenge carried a scope param (e.g. the very first pre-token 401 that kicked off authorization — RFC 6750 servers routinely include one), or that the current 401 does.

Step-by-step regression

1. Initial connection: server returns 401 with WWW-Authenticate: Bearer scope=\"read\" → transport records _scope = 'read', user completes interactive auth.
2. Token response omits scope (granted == requested, per §5.1) → stored tokens are { access_token, refresh_token } with no scope field.
3. Later, the access token expires; the server returns a routine 401.
4. Transport calls onUnauthorized with ctx.scope = 'read' (new in this PR) → unionScope = 'read', tokens?.scope = undefined → isStrictScopeSuperset('read', undefined) → true → forceReauthorization: true.
5. authInternal (auth.ts:1313) skips the refresh_token branch entirely when forceReauthorization is set and starts a fresh authorization request; for interactive providers that calls redirectToAuthorization and returns 'REDIRECT', so handleOAuthUnauthorized throws UnauthorizedError and the user is bounced through the consent flow on every ordinary token expiry.

Before this commit, handleOAuthUnauthorized never passed forceReauthorization, so step 3–5 was handled by a silent refresh + retry. This is therefore a concrete behavioral regression introduced here, not a pre-existing quirk.

Why the existing code doesn't prevent it

The isStrictScopeSuperset doc comment describes its "conservative" treatment of an absent token scope, but that reasoning was written for the 403 insufficient_scope step-up path, where the server has explicitly said the current grant is insufficient and forcing a fresh authorization is the right call. A plain 401 is overwhelmingly token expiry, where the refresh token is exactly the right tool. The same PR demonstrates awareness of this distinction in the sibling paths: withOAuth (middleware.ts:66) guards with lastTokenScope !== undefined && isStrictScopeSuperset(...), and _stepUpAuthorize reconstructs the previously-requested scope from discoveryState/clientMetadata before comparing precisely so an omitted token scope isn't treated as "no prior grant". handleOAuthUnauthorized does neither, so the two 401 paths this PR touches are inconsistent.

Impact

For any provider whose token responses omit scope and any deployment where a challenge scope has been observed (or the transport accumulated one), every access-token expiry becomes an interactive consent bounce (browser redirect) or a hard UnauthorizedError for non-interactive clients — instead of the silent refresh that worked before this PR. This affects Streamable HTTP, legacy SSE, and the raw handleOAuthUnauthorized helper.

How to fix

Gate the force the same way withOAuth does in this PR:

const forceReauthorization = tokens?.scope !== undefined && isStrictScopeSuperset(unionScope, tokens.scope);

or reconstruct the previously-requested scope (transport ctx.scope, then PRM scopes_supported, then clientMetadata.scope) the way _stepUpAuthorize does and compare the union against that, so a genuinely widened challenge still forces re-authorization while a routine expiry keeps using the refresh token.